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REMOTE MONITORING, CONFIGURING, PROGRAMMING AND 
DIAGNOSTIC SYSTEM AND METHOD FOR VEHICLES AND VEHICLE 

COMPONENTS 

REFERENCE TO RELATED APPLICATIONS 
[0001] This application is a continuation-in-part claiming the benefit of commonly 
assigned, co-pending U.S. Patent Appln. No. 09/640,785, filed August 18, 2000 
entitled "System, Method and Computer Program Product for Remote Vehicle 
Diagnostics, Monitoring, Configuring and Reprogramming" to Bromley et al., the 
disclosure of which is incorporated by reference in its entirety. 

TECIBSHCAL FIELD 
[0002] The present invention relates generally to computer data and information 
systems, and more particularly to computer tools for storing, processing, and 
displaying vehicle information. 

BACKGROUND OF THE INVENTION 
[0003] It is common for companies to own a large number, or fleet, of commercial 
motor vehicles. Typical examples of such companies include conmiercial courier 
services, moving companies, freight and tmcking companies, tmck leasing 
companies, as well as passenger vehicle leasing companies and passenger carriers. To 
TnainffliTi profitability, a company owning a vehicle fleet ideally minimizes the time 
spent in vehicle maintenance and repair. Maintaining optimum vehicle performance 
often involves removing vehicles firom service to conduct fault analysis, scheduled 
maintenance, diagnostics monitoring and parameter modifications. 
[0004] Further, companies that manufacture vehicle components may wish to have a 
central database to access information for product improvements, warranty service, 
diagnostics, and other component data after components have been installed on the 
vehicle. Because different companies and different industries have different vehicle 
data gathering and reporting needs, current solutions involve constructing specialized 
systems for each particular user application. 
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[0005] There is a desire for a system that can monitor, configure, program and 
diagnose vehicles and/or vehicle components while allowing customization of ttie 
vehicle data to accommodate the different needs of different users and different 

SUMMARY OF THE INVENTION 
[0006] Accordingly, one embodiment of the present invention is directed to a system 
for monitoring, configuring, programming and/or diagnosing operation of at least one 
vehicle, conq>rising an on-board unit disposed on the vehicle to send and receive data 
conresponding to at least one vehicle operating characteristic, a plurality of modular 
applications, each application having an associated fimction that process^ tiie data 
corresponding to said at least one vehicle operating characteristic obtained via the on- 
board unit, and an interface that allows selection among the plurality of modular 
applications to create a customized. 

[0007] Another embodiment of the invention is directed to an on-boaid unit disposed 
on a vehicle for use in a system for monitoring, configuring, progranmiing and/or 
diagnosing operation of at least one vehicle, comprising at least one on-board unit 
interface to support communication between the on-board unit and at least one device 
outside the on-board unit, a processor that manages the data sent and received by the 
on-boaid unit via said at least one interface, and a memory coupled to the processor. 
[0008] A fiirther raibodiment of the present invention is directed to a method for 
monitoring, configuring, programming and/or diagnosing operation of at least one 
vehicle, comprising obtaining data corresponding to at least one vehicle operating 
charactOTStic firom an on-board unit on the vehicle, providing a plurality of modular 
{^plications that are selectable by die user to create a customized system, and 
processing the data corresponding to at least one vehicle operating characteristic 
obtained via the on-board unit according to at least one fimction associated with at 
least one selected modular application. 

[0009] Further embodiments and variations of the invention will be appzr&at from the 
drawings and description below. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0010] Figure 1 is a representative functional block diagram illustrating an overall 
system according to one embodiment of the present invention; 
[0011] Figure 2 is a representative block diagram illustrating a systrai architecture 
according to one embodiment of the present invention; 

[0012] Figures 3 A and 3B are representative block diagrams of one embodiment of an 
on-board unit in one embodiment of the present invention; 

[0013] Figure 4 is a block diagram of a parameter retrieval process according to one 
embodiment of the present invention; 

[0014] Figure 5 is a block diagram of a parameter retrieval process according to 
another embodiment of the present invention; 

(001 S] Figure 6 is a block diagram of a parameter retrieval process according to yet 
another embodiment of the present invention; 

[0016] Figure 7 is a graph illustrating the operation of a threshold alert process 
according to one embodiment of the present invCTtion; 

[0017] Figure 8 is a block diagram illustrating the operation of a tamper alert process 
according to one CTibodiment of the present invention; 

[0018] Figure 9 is a block diagram illustrating a parameter change process according 
to one embodiment of the invention; 

[0019] Figure 10 is a block diagram illustrating one possible architecture for a remote 
diagnostics application to be used in one embodiment of the present invention; and 
[0020] Figure 1 1 is a block diagram illustrating one possible architecture of a leased 
vehicle management application to used in one embodiment of the present invention. 

DETAILED DESCRIPTION OF THE EMBODIMENTS 
System functionalities and architecture 

[0021] Figure 1 is a representative fimctional diagram of a vehicle monitoring and 
diagnostics system ICQ according to one embodiment of the present invention. 
Generally, the inventive system 100 allows monitoring and control of a vehicle fleet 
by displaying and controlling data according to a user's customized specifications. 
The system 100 is designed with modular q)plications that interact with core data and 
services so that vehicle parameters can be monitored, analyzed and displayed in a 
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fonnat that is meaningful to a particular user and/or a particular industry. This 
flexibility allows differrat users and/or industries to use the same overall system 100 
for vehicle and component monitoring despite their disparate vehicle data 
requirements. 

[0022] Referring to the Figure, tibte system 100 may include an application service 
provider (ASP) infrastructure 102 tiliat acts as a gateway between a plurality of 
vehicles 104, each vehicle having an associated on-vehicle computer (e.g., an on- 
board unit or "OBIT' ICS) and customizable interface 106. The inter&ce 106 allows a 
user or machine 106a to select among various applications, such as third-party 
applications 108 as well as original, system-supplied applications 1 10, to obtain and 
analyze various data from the vehicles 104, The applications may include, for 
example, tools for obtaining real-time fleet characteristics, trend axialysis and 
diagnostics, to perform manual, dynantiic or rule-based configuration, as well as allow 
fleet managers to provide real-time driver/fleet notification. To ensure that the user 
receives data that is meaningful to the user's specific £q[>plication, the user interface 
106 can be customized to operate applications selected by the user. In the example 
shown in Figure 1, different types of users 106a may select different applications as a 
customized application group 1 12 to accommodate their specific data monitoring and 
reporting needs s^plicable to their own business. 

[0023] For example, as illustrated in Figure 1, a deal^/repair facility may select from 
the offered applications 108, 110, vehicle configuration, scheduled maintenance, 
remote diagnostics, and concierge services as its application group 1 12, while a truck 
manufacturer may select a different collection of applications 112, such as wairanty 
service/campaign support, vehicle history, and guided diagnostics. By offering a . 
variety of modular apphcations 108, 110, that can be selected and combined 
according to the needs of a particular user, the same infrastrocture 102 can be 
customized and used by different users for different purposes with little or no 
modification of the infirastructure 102 itself FurOier, by allowing users to access 
third-party ipplicaitions 108 tiirougjh the same infiriastructure as system supplied 
i^lications 1 10, the system 100 can leverage services not provided by the system 
100 itself, further increasing flexibility and adaptability. 
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[0024] Furthear, in an embodiment of the inventive system using an ASP-based model, 
an application service provider provides and allows access, on a subscriber basis, to a 
remote vehicle diagnostics, monitoring, configuration and reprogramming tool via the 
Internet. That is, the application service provider provides the hardware (e.g., servers, 
an on-vehicle computer) and software (e.g., database) infrastructure, application 
software, customer support, and billing mechanism to allow its customers (e.g., fleet 
managers, vehicle distributors, vehicle dealers, original equipment manufacturers 
("OEMs")> leasing/r^tal companies, and the like) to remotely access the vehicles 
within a fleet. The tool can be used by subscribers to select and access the modular 
applications 108, 110. 

[0025] Note that an ASP-based model can eliminate the need to physically distribute 
software to users. Instead, new features and updates can be immediately available to 
users because the system resides and runs on an application servo*. In one 
embodiment, applications that are not on the application server can reside on the OBU 
105. The on-board unit ^phcations can be loaded onto the OBU 105 during vehicle 
installation, and additional applications or ^plication updates can be downloaded 
onto the OBU 105 through a wireless network coimection. 
[0026] Figure 2 is a representative block diagram of a system architecture 200 
according to one embodiment of the present invention. The system architecture 
shown in Figure 2 is one possible way for carrying out the functionalities described 
above and shown in Figure 1 . In tiiis example, the architecture includes tiiree primary 
con^onents: the interface 106, a server 202, and the on-board unit (OBU) 105. All 
three components 106, 202, 105 are designed to communicate with each other through 
any known means, such as via wireless networks 206. 

[0027] The interface 106 can be, for example, a user interface and/or a machine 
interface that allows a human or machine to access the mufrastructure 102, which 
includes the server 202. The server 202 may include, for example, a series of servers 
that perform web page hosting, run applications, perform data storage, and/or perfomi 
wireless communications network management. In this example, the server 202 
includes a web/application server 202a, a vehicle server 202b, and a communications 
server 202c, all of which are linked to a database server 202d. As ^own in the 
Figure, the server 202 acts as a link between a web based client (user) 106 with the 
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OBU 1 05, allowing user access and control to a vehicle data stream via the Internet 
210 or other internetworking system. 

[0028] The OBU 105 access the data from various vehicle components and may also 
generate vehicle data of its own to provide to the server 202. The OBU 105 may 
include a wireless communication module 105a to provide a communication link to a 
wireless network, a vehicle data processing module 105b to process data obtained 
from the vehicle componrats, and a vehicle interface 105c connected to, for exanqple, 
file vehicle data bus to gather data from the vehicle coniponents for processing and 
managing time or process-critical functions with the vehicle systems, such as 
electronic control units. The OBU 105 may also include a global positioning system 
and a driver display interface. 

[0029] Each of the system architecture components will be described in greater detail 
below. 

Interface 

[0030] The interface 106 may be a standard browser interface and/or a machine*to- 
machine interface. In the browser interfrtce, a human user accesses the system via a 
standard web browser. In one embodiment, the user gains access to the specific set of 
their authorized vehicles and functions after login and password authorization. In a 
machine-to-machine interface, server and vehicle data and fimctions may be 
accessible via a secure application program interface (API)* A machine-to-machine 
interface allows other applications access to the system*s 100 capabilities so they can 
gain remote access to the vehicle and the capabitities offered by tiie system. This 
allows the system 100 to interface with existing or planned back office ^plications 
and operations, making the system 100 suitable for integration with, for exanq)le, 
overall fleet operations or other systems. 

Server 

[0031] The server system is flie fixed-based conq>onent of the system and, as 
explained above, can be an Intraiet-based system and use an ASP model. The end 
user can access the system fix>m the interface 106, such as any commercially available 
web browser. As noted above, the server 202 in this embodiment includes the web 
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application server 202a, the vehicle server 202b, and the communications server 202c, 
and the database server 202d. Each of these will be described in greater detail below. 
[0032] The web application server 202a contains the logic defining one or more 
applications to an end user. All the data needed for a specific user application is 
requested and sent to the OBU 105 via the wireless communication network 206. As 
will be cTqplained in greater detail below, applications perform the necessazy 
calculations and then package the results for presentation in a defined fomiat to the 
user. Further, the web application server 202 is responsible for running business 
applications related to user activities, which may include perfonning business logic, 
interfacing to the systems databases for fleet, vehicle, component, and transaction 
activity, knowledge-base storage, and sending user requested vehicle queries or 
functions to the vehicle server 202b and the conununications server 202c. 
[0033] The vehicle server 202b in the server 202 stores and processes vehicle-specific 
data and acts as a translator between the appUcations 108, 110 and the specific vehicle 
and/or vehicle component. More particularly, the vehicle server 202b is responsible 
for processing data requests and vehicle responses and converting the outbound and 
inbound data into traoslated vehicle infonnation. 

[0034] The vehicle server 202b translates user requests fi:om the interface 106 into 
formats specific to the vehicle 104 to which the request is directed. The vehicle 
server 202b conducts this translation without any user interaction or property 
selections. For example, the vehicle server 202b may evaluate a message being sent 
to a particular vehicle and detect the vehicle type, the vehicle bus type, and the 
vehicle component or sub-component that is intended as the message recipient. The 
vehicle server 202b then packages the message according to the specific 
communication protocol mandated by the recipirait component. As a result, the 
vehicle server 202b allows monitoring and control of difEarent vehicles having 
different components through the same interface 106 for a given user and application. 
[0035] As shown in Figure 2, one embodiment of the inventive system allows 
communication between at least the vehicles 104 and the server 202 via a wireless 
network, such as a satellite or terrestrial based network. A conmiunication server 
202c may be included in the server 202 to support wireless commimications and 
provide a central location for supporting changes and improvements in wireless 
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technology. In one embodiment, the communication server 202c manages the 
communications activities between the OBU 105 and the vehicle server 202b and 
processes vehicle/component specific requests between the OBU 105 and the server 
202b. 

[0036] In one embodiment, the communications server 202c utilizes a wireless 
communications firamework that provides a communication link between the server 
202 and the vehicle 104. Although any wireless mobile communication system can 
be used in the inventive system 100, a flexible wireless communication uifirastracture 
that is cs^able of handling multiple platforms and/or multiple communication 
providers is preferred. One possible embodiment of such a framework is described in 
U.S. Provisional Application No, 60/351,165 (Attorney Docket No. 65855-0060), 
entitled "Wireless Communication Framework", filed January 23, 2002, the disclosure 
of which is incorporated herein by reference in its entirety. To handle multiple 
communication providers and/or platforms, the flexible wireless communication 
infiastructure may abstract the needs of a specific wireless communication provider, 
such as the message size, message format, and specific protocol details, into a 
standard messaging API understandable by multiple systems and platfomiis. In one 
embodiment, the communication server 202c abstracts messages, and stores and 
forwards messages to ensure later delivery of messages to vehicles that are 
teoq^orarily outside a wireless communication coverage area, and may even include 
least cost routing rules to select among multiple wireless networks to prioritize 
message routing based on cost and/or criticality of the message. 
[0037] The server 202 also includes a database server 202d containing relational data 
tables designed to retain information pertaining to a user, a vehicle, a fleet, system 
transaction history and other relationships associated with a given vehicle 104, The 
database server 202d also may be designed to retain the data resulting fi-om any 
vehicular transaction, such as transactions between the OBU 105 and the server 202. 
In one embodiment, the database is structured such that authorized users can access 
vehicles in a number of ways, for example, by fleet ownership, leasing fleet, vehicle 
manufacturer, and component manufacturer. This stmcture enables fhe syston 100 to 
provide each of tfiese beneficiaries with specific, customized data and access in a 
format meaningfiil to each user. 
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On board unit fOBm 

[0038] As noted above, the OBU 105 provides the vehicle-side, real-time computing 
base for the system. In one embodiment, the OBU 105 is responsible for data stream 
processing, discrete measurements, vehicle position information, wireless 
communications, and real-time analysis of data. Within the system's overall 
framework, the OBU 105 acts as a vehicle server, providing vehicle specific data and 
functionality. In one embodiment, the OBU 105 may be an expandable custom 
hardware platform designed and manufactured to reside on a wide variety of vehicles 
with different component specifications and needs and is preferably capable of 
running multiple applications while acting as a vehicle data gateway for others. 
[0039] Figures 3A and 3B are representative high-level block diagrams of the OBU 
105. One embodiment of the OBU 105 may include a data processor 300 and one or 
more interfaces 302, 304, 306 such as a wireless interface 302 ^t controls 
communication between the OBU 105 and tiie server 202 via the wireless network 
206, a vehicle int^r&ce 304 that aUows the OBU 105 to transmit to and receive Scorn, 
for example, electronic control units (ECUs), vehicle controllers, and/or oth^ vehicle 
components 308, and an optional user interface 306 that allows a user to read and/or 
enter information into the OBU 105. 

[0040] The wireless interface 302 in one embodiment sends and receives data fix>m 
the server 202 to and fi-om the OBU 105 and abstracts communications fix)m different 
wireless network devices to allow the OBU 105 to communicate with a flexible 
wireless communication infrastructure, such as the type described above witii respect 
to the server 202. More particularly, the wireless interface 302 may encapsulate 
protocol differences among various wireless network devices to provide a standard 
output to the processor 300. In one embodiment, wireless network messages are 
routed from the server 202 to the wireless interface 302 for error checking and 
filtering. After filtering, conunands are passed to the processor 300 and then routed to 
their respective vehicle components. 

[0041] The processor 300 acts as the central processing unit (CPU) of the OBU 105 
by managing the sending and receiving of requests between the server 202 and the 
vehicle 104 via the wireless interface 302. In one embodiment, the processor 300 has 
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the logic and intelligence to carry out vehicle specific services such as diagnostic 
requests and processing . For example, the processor 300 may run specific 
applications that are loaded into the OBTJs memory 315, 316, 318 and coordinates 
activities between the vehicle datastream, GPS unit, wireless communications, and the 
r^ote server 202. Further, in one embodiment, the processor 300 can be updated 
through the wireless network to add and enhance its functionality. This capability 
eliminates requiring the vehicle to be at the service bay for software updates that 
CThance features and functionality. 

[0042] The vehicle interface 304 allows the OBU 105 to support a wide variety of 
vehicle components and subcomponents. Possible interfaces that can be supported by 
the OBU include SAE J1708, SAE J1939, SAE OBDII/CAN, ISO-9141, discrete I/O, 
proprietary interfaces, and other interfaces (e.g., discrete or instrumentation 
interfaces). Further, the vehicle interface 304 provides a single point of contact for all 
vehicle components and control devices on the vehicle 104, allowing the 
conmumication between OBU software with the vehicle's actual data bus line as well 
as wireless communication devices, such as a satellite-based communications system. 
[0043] In one embodiment, tiie vehicle interface 304 may include a data 
parser/requester module 310 that contains software code logic that is also responsible 
for handling direct inter&cing between tiie processor 300 and the vehicle data bus 307 
for non-q)plication specific (i.e., "generic" SAE J1708 or SAE1939 disarete 
measurement points) parameter readings, alerts, configuration or reprogramming data, 
as explained in greater detail below. 

[0044] The vehicle interface 304 may also include, for exan^le, one or more 
appUcation specific modules 312, such as one for each manufacturer specific 
controller 308 within the vehicle 104, each containing software code logic that is 
responsible for handling interfacing between the processor 300 and the vehicle data 
bus 307 (via data parser/requestor module 310 in this example) for appUcation- 
specific parameter readings, alerts, configuration or reprogramming data. 
[0045] Note that the OBU 105 may act as a server and/or data gateway for an 
implication that places data directly on the vehicle data bus 307. In one embodiment, 
tiie OBU 105 uses an interface standard, such as TMC RP 1210A, as an element of 
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the data gateway. Regardless of the specific standard used, any activity using the 
OBU 105 as a data gateway will involve data going through the processor 300. 
[0046] In an embodiment of the present invention, the OBU 105 is designed to be 
compliant with the SAE's Joint SAE/TMC Recommended Environmental Practices 
for Electronic Equipment Design (Heavy-Duty Trucks)^ Document No. J1455 (August 
1994) standard, which is incorporated herein by reference in its entirety, because it 
will be a conq[>onent included (or installed) within vehicles 104. As indicated above, 
the OBU 105 is not limited to be compliant with any particular standard and can 
accommodate any on-board electronic system standard (e.g., SAB J1708, SAE J1939, 
SAE J1850, ISO 9141, proprietary data streams, etc.) for any sub-system (e.g., 
engines, transmissions, braking systems, instrument clusters, etc.) as long as the 
system 100 is capable of converting commands between the interface 106 and flie 
OBU 1 05 according to whatever standard is used by a given vehicle electronic 
system. If the vehicle electronic system uses a proprietary standard, for example, the 
vehicle server 202b and the associated appUcation specific module 312 on flie OBU 
105 may be adapted to accommodate &e proprietary standard. 
{0047] Figure 3B illustrates another embodiment of the OBU 105 and e:}q>licitly 
shows the capability to interface wifli other devices via, for example, a parallel 
interface, serial interface, universal serial bus (USB), sateUite, terrestrial wireless 
(e.g., 802. 1 lb), and/or a global positioning system (GPS). More particularly, the 
embodiment of the OBU 105 shown in Figure 3B includes a GPS circuit 313 that 
receives signals firom a GPS anteima and a serial interface 3 14 that communicates 
with a driver interface or other on*vehicle devices (not shown), such as a handheld 
device, a cellular telephone, voice messaging system, data logg^, or other devices. 
Figure 3B also explicitly illustrates a flash memory 315, a dynamic random access 
memory 316, and an optional compact flash memory 318 coupled to the processor 
300 as well as a power supply 320 coupled to the vehicle battery and ignition switch 
(not shown). Those of skill in the art will understand that the elements and concepts 
shown in Figures 3 A and 3B can be combined in any manner without departing fix>m 
the scope of &e invention. 

[0048] The appUcation software and the spplication framewoik is built with both a 
software and hardware abstraction layer. This approach makes the framewodc 
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adaptable to a number of alternative operating system and hardware platforms. One 
embodiment of the OBU 105 may use any known real-time operating syst^. 

System operation examples 

[0049] The overall system 100 can support many possible services and applications, 
examples of which are described below and illustrated in Figures 4 through 8. As 
noted above, the system 100 shown in Figures 1 and 2 illustrate one possible 
relationship between services and ^plications for a system 100 using an ASP-based 
model. la one embodiment, a group of core services 350 Uiat perform vehicle- 
specific operations are available to the appUcations 108, 110. As noted above, the 
appUcations 108, 1 10 allow a user to customize the interpretation and display of the 
vehicle-specific operations based on the usei's own requirements. The core services 
350 act as building blocks of services that can be selected or combined in any desired 
manner, and can be accessed by or with any applications 108, 1 10 in the system 100; 
in other words, the applications 1 08, 1 10 act as a functional layer over the more 
primitive core services 350. For example, the core services 350 may be accessed by a 
help desk application to obtain vehicle location along with parametric data or by a 
sendee application to obtain parametric data and to perform functional tests. Because 
the system 100 can leverage other appUcations and services that the system 100 itself 
may not have and couple them with its own applications and services, the system 100 
provides a flexible and adaptable platform that can accommodate many different 
needs. 

[0050] In one embodimrat, the applications may assemble the core services to 
perform specific functions. For example, one of the core services 350 may cq>ture 
measured values and/or change parameters or operational settings in the vehicle 104 
while the appUcations 108, 1 10 organize and process information fix>m the core 
services 350 into groupings that are meaningful to a given user. A service outlet, for 
example, may want different data and/or data organized in a different manner than a 
leasing organization or a component manufacturer. 

[0051] As noted above and as shown in Figures 1 and 2, the interface 106 can be a 
browser interface or graphical user interface (GUI) that allows a human user to access 
the system 100, or a machine-to-machine appUcation programming interface (API). 
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The user interface 106 allows the system 100 to act as a gateway between the user and 
the vehicle(s) 104 via the ^plications and services. 

[0052] As noted above, the core services 350 provided by the system 100 act as 
building blocks that can be assembled by applications in a variety of ways that can 
best serve the user. Possible core services 350 include: 

Parameters: obtains discrete or data stream-based vehicle parameters, 
including standard and proprietary messages, upon user request; 
^/erts: notification of the occurrrace of a particular event (e.g., receipt of a 
trouble code or a notification of a parameter value occurring outside an 
acceptable parameter range); 

Functions: runs fimctional tests on vehicle components and generates result 
reports; 

Configuration: perforais remote configuration of a vehicle or component by, 
for example, changing one or more vehicle parameters; 
Reprogramming: performs complete reprograrmning, or "re-flashing" of a 
selected on-vehicle controller; 

Geographic location: provides vehicle location through, for example, a GPS 
system. 

[0053] The list of core services 350 above is not meant to be exhaustive, but are 
simply examples of possible services that can be available directly to users or 
siqpplied to applications for further processing. Note that although the e^lanations 
below focus on obtaining data from a vehicle ECU 308, the system and fimctions 
described below are applicable for any vehicle data. 

[0054] The "Parameters" service may include a simple parameter retrieval service as 
well as more sophisticated parameter retrieval services that address limitations in 
obtaining vehicle data when, for example, the vehicle is turned off. Figure 4 
illustrates one simple process 400 for obtaining a parameter. When the OBU 105 
receives a command firom the server 202 to retrieve a data value at block 402, the 
OBU 105 sends a query message to the ECU 308 to obtain the BCUs current reading 
at block 404. Once the ECU 308 returns a parameter value at block 406, the OBU 
105 retrieves the value and forwards it to the server at block 408. Note that frequently 
used parameters may be packaged and transmitted to the server 202 as a single 
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message as a more efficient, way of transferring data. Further, the specific means for 
getting a particular data item may depend on the specific requiremrats of a given 
ECU 308. For example, as is known in the art, data points corresponding to an anti- 
lock brake system may be obtained in a different maimer than data corresponding to 
engine coolant temperature. 

[0055] Figure 5 is a flowchart illustrating one possible process to be offered as a 
"Parameters" service that is more sophisticated that the simple parameter retrieval 
service explained above. Although parameter data can simply be read fiom the 
vehicle's electronic controllers and provided to the user on demand, ttie *Tarameters" 
service can also provide more sophisticated parameter data c^ture methods such as 
the type shown in Figure 5. Figure S illustrates a "snapshot" process 500 for 
obtaining a set of parameter values over a period of time, where the r^ordng of fhe 
parameter values is triggered by a specified event. Offering this service as an on- 
vehicle diagnostic tool is particularly helpfiil for intermittent fault diagnosis and 
v^cle performance analysis. Further, gathering data sets at prescribed periodic 
intervals minimizes negative effects caused by inherent problems in wireless 
commimication systems, such communications drop-out and lack of coverage, which 
would normally make remote diagnostics ineffective. 

[0056] To carry out the snapshot process 500, the system 100 first initializes at block 
502 by, for example, storing the diagnostic parameters to monitor, setting the time 
intervals at which parameter values are captiured, selecting the number of captured 
values to be included in a single report, and selecting the event that will trigger 
reporting of the cs^tured values. This information can be inputted into the OBU 105 
via the interface 106. The parameter values to be captured can be any parameters 
accessible on the vehicle's electronic controllers by means of a diagnostic data stream 
or fix>m discrete inputs on the OBU 105. The triggering event can be any non- 
continuous event that is monitored on fhe vehicle, such as die capture of an active 
trouble code fi-om a vehicle controller or a parameter moving outside an established 
acceptable range. 

[0O57] Once the OBU 105 has been configured (block 502), the OBU 105 maintains a 
number of historical value sets at block 504 by caching a selected number of 
parameter readings during normal vehicle operation. While the OBU 105 captures the 
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parameter readings, it also waits for the triggering event to occur. Once the trigger 
event occurs (block 506), the OBU 105 continues caching the configured parameter 
readings occurring after the event (block 508). The number of historical value sets 
can be, for example, half the niunber of captures to be included in the final report, 
while the niunber of value sets taken after the triggering event can make up the other 
half. Note that the OBU 105 may, in another embodiment, capture parameter 
readings only before or after the triggering event as well or capture different numbers 
of values on either side of the event 

[0058] After all of the desired value sets have been captured and collected, all of the 
captured readings, both before and after the event, are combined into a filial report at 
block 5 10. The report can be stored on the OBU 105 for later retrieval or sent via 
wireless connection to the application server 202a for immediate viewing. 
[0059] Another possible process that can be offered as a "Parameters** service is a 
"get stored values" (GS V) process 600, as illustrated in Figure 6, for collecting 
parameter values fi^om a vehicle even if the vehicle is unable to provide current 
parameter values at the time of the query. The GSV process 600 addresses a situation 
where the vehicle controllers 308 are unable to respond to a query by the OBU 105 
(e.g., while the vehicle is turned off) to respond to a query. This process is 
particularly useftil in applications requiring remote retrieval of time-sensitive data, 
such as an odometer reading at the end of a scheduled period, or in any implication 
^ere the vehicle operating state is unknown at Hie tune of flie query. 
[0060] For the GSV process 600 to be effective, the OBU 105 should be designed to 
allow continuous remote access so that the OBU 105 is always ready for receiving 
and sending messages. The OBU 105 is initialized by receiving an instmction to 
periodically collect specified parameter data at a selected query time interval (block 
602). After receiving this conunand, the OBU 105 will periodically collect data at tihe 
specified query time intervals (block 604). The values gathered by the OBU 105 are 
stored in the on-board unit's memory, such as a flash memory, at block 606 before the 
OBU 105 is shut down when the vehicle 104 is turned off. 
[0061] If the OBU 105 receives a GSV "retrieve" conmntand firom the application 
server 202a (block 608), Ihe OBU 105 checks the state of the vehicle controller 308 at 
block 610. If ttie vehicle controller 308 is accessible, tiien the OBU 105 collects the 
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cuirent values from the vehicle controller 308 at that time and sends the collected 
current values to the server 202. If the vehicle controller 308 is not available at the 
time of the command (e.g., if the vehicle is turned off), making the current values of 
the controller 308 unretrievable, the saved values in the OBU 105 are sent back to the 
server 202 as the retrieved values (block 612), 

[0062] By periodically collecting data at selected intervals while the vehicle 
controller is operational, the OBU lOS can at least obtain recent vehicle controller 
parameter readings before the controller 308 is inaccessible at some later time. As a 
result, the GS V process 600 allows the rraiote server 202 to obtain the most recent 
controller data if current data is not available at the time of the query. In short, the 
GSV process 600 returns the last known value in memory to the server 202 if the 
vehicle is turned on and will retrieve a backup value, which may still be the last 
known value in memory, if the vehicle is turned ofif. 

[0063] Multiple "Alerts" services may also be provided as a core service in the system 
100. In its simplest form, the "Alert" service monitors vehicle trouble codes and 
transmits a message to the OBU 105 when the trouble code occurs. For example, a 
fault code may come as solicited or unsolicited, depending on how the controller 308 
in the OBU 105 is instructed to handle faults. To obtain an unsohcited fault, the OBU 
105 monitors the vehicle data bus 307 for the occurrence of a faidt and notifies the 
server 202 if a fault occurs. If only a set of individual faults are monitored, 
additional parsing shall be performed to filter out unwanted faults. For example, if a 
user only wishes to be informed of fault codes corresponding to a component 
breakdown, as opposed to being informed of all fault codes, the user can indicate this 
preference via the int^ace 106. 

[0064] To obtain a solicited fault, the user may set up pmodic queries to the OBU 
processor 300 in addition to setup notification. Note that the response message may 
match the message template even if no fault actually existed; in this case, additional 
parsing of the response message may be necessary to obtain usefiil information. For 
example, if the user solicits a request for information, the user may obtain a response 
based upon the criteria of that request, which may be different than the criteria for 
unsolicited notifications. 
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[0065] If desired, the "Al^" service may include additional fiinctions such as 
providiag the ability to add/remove individual faults, canceling the alert function for a 
given fault when a fault alert is fired so that only the first fault occurrence (and not 
subsequent fault occurrences) trigger a notification message, or configuring the 
"Alert" service to be stored permanently in, for example, the database server 202d 
until the user removes the service or until the service is cancelled by a fault 
occurrence. 

[0066] With respect to the example shown in Figure 7 and as noted above, the 
"Alerts** service may include among its functions the detection of a particular event by 
checking whether a monitored value exceeds a selected threshold. Note that although 
this example focuses on one diagnostic parameter, any number of diagnostic 
parameters may be combined into an algorithm to detect threshold limit boundaries. 
Further, values may be monitored over time, rather than as one single alert-triggering 
event, to monitor patterns and trends and to detect evOTits more accurately. 
[0067] As an example of a "Alert" service that monitors over time. Figure 7 shows an 
"Over RPM" threshold alert example that detects if a vehicle driver is abusing the 
vehicle engine. In this example, the Over RPM threshold alert considers the amount 
of time that the RPM level exceeds a specified Umit (6000 RPM in this example) 
rather than simply generating an alert each time the RPM exceeds the level The time 
delay ensures that alerts are generated only for events that may cause genuine 
concenu 

[0068] As shown in Figure 7 if the RPM exceeds 6000 RPM for a brief period that is 
less than 2 seconds (at 702), the "Alert" service does not generate an alert. However, 
if the RPM does exceed 6000 RPM for more than two seconds (at 704), the service 
fires an alert 707 and resets itself (at 708) when the RPM drops back below 6000 
RPM. The actual circuitry for monitoring RPM and implementing this example of the 
"Alert" service in the system 100 (e.g., on the OBU 105) is well within the skill of 
those in the art. Further, the time delay concept shown in Figure 7 can be used for 
any parameter where undesirable operation is preferably detected via time and value 
thresholds. 

[0069] The "Alert" services may also include a tamper alert feature, as shown in 
Figure 8, that allows the user to monitor any unauthorized alteration of configurable 
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parameters. This feature 800 generally contains a setup process 802 and a tamper 
check process 804. When a user requests the tamper alert service (block 806), OBU 
105 captures the value of the parameter at the time of the request and saves the 
parameter value to a file in the OBlPs memory (e.g., flash memory 315 or DRAM 
3 16) at block 808. Note that this parameter retrieval process may involve ixsing the 
"Parameters" service as explained above to query the ECU or other vehicle controllCT 
or component 308. 

[0070] The actual tamper check process is conducted when, for example, the vehicle 
is initially turned on. At this point, the OBU 105 checks the parameter again to get its 
current value at the time the vehicle ignition is turned on (block 810). If flie current 
value is different fiian the saved value (block 812), a tamper alert message will be 
returned to the user (block 814). If die compared values are the same at block 812, 
however, the vehicle continues operation as usual without transmitting any tamper 
alert signal (block 816). In one onbodiment, the user may add/remove individual 
tamper alerts, and the tamper alert may be cancelled at block 818 once the alert is 
fired. 

[0071] A "Change Parameters" fimction may also be included as part of a 
configuration core service, as shown in Figure 9. This feature may allow a user to 
remotely insert or update, for example, a parameter or message defimtion in the 
vehicle. As shown in Figure 9, the function 850 includes receiving a parameter 
change request (block 852), receiving the specific parameter to be changed in the 
vehicle (block 854), changing Hie parameter (block 856), and saving the parameter in 
memory (block 858). In one embodiment, the updated parameter definitions are 
stored permanently in memory until the next change request. Further, in one 
embodiment, the updated definition takes effect as soon as the update is completed. 
[0072] The core services can be accessed by one or more applications, as noted 
above. The system 100 may include the abiUty to leverage other services that it may 
or may not have, such as. Fuel Tax Rq>orting/State Line Crossing applications. Asset 
tracking/utilization programs. Driver Performance appUcations, On-line Vehicle 
Documentation, detailed mapping applications, etc. This flexibihty, coupled with 
modular services and applications 108, 1 10 that can be added, subtracted, and 
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combined at will, provides for a very flexible and adaptable platform. 



Applications 

[0073] As described above, the system 100 allows users to cxistomize their own 
vehicle monitoring, programming and diagnostics systems based on their own 
specialized needs by offering a plurality of applications that can be selected and 
combined in a modular fashion as desired by the user. The applications may include 
service offerings such as Remote Diagnostics, Fuel Economy, Trip Reporting, 
Automatic Vehicle Location based upon GPS or satellite based system information, 
and others. The applications listed here and described in greater detail below are only 
examples and are not meant to be limiting or compreh^ive in any manner. Those of 
skill in the art will understand that other applications may also be included as possible 
application options. 

[0074] A "Remote Diagnostics" application, for example, provides the ability to 
perform component analysis before or during a vehicle breakdown and allows vehicle 
maintenance locations to receive parametric information from a vehicle prior to its 
arrival, or prior to dispatching a technician to the vehicle. Further, the "Remote 
Diagnostics" ^pUcation allows a technician to perform selected diagnostic tests on 
the vehicle or system, with the test process being managed by the OBU 105. In one 
embodknent, the "Remote Diagnostics" explication allows a user to view parameters, 
active and inactive fault codes, and vehicle configurations, for example, and may also 
allow authorized users to perform functional tests and configuration changes on the 
vehicle. Remote Diagnostics may be initiated whoi, for exaiiq)le, a vehicle notifies 
the fleet based upon a series of established alerts or when the diagnostics are 
requested manually by a fleet authorized user. In practice, the application may 
provide diagnostic applications via the inventive system 100. When the user logs on 
to the system 100 via the interface 106, for example, he or she may be presented with 
a list of vehicles that have reported alerts or notifications that may need attention. If 
no alerts are active, the user is provided a list of vehicles for which he or she is 
responsible. At this point the user may elect to xise a remote diagnostics application, 
such as the remote diagnostics application described below and shown in Figure 10, 
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912, to perfonn further analysis on the vehicle to detOTnine the severity of the 
problem. 

[0075] Figure 10 is a block diagram illustrating one possible overall web site 
architecture 900 that includes a remote diagnostics application. In this example, a 
user may log into the application (block 902) to reach an appUcation home page 904, 
From the home page, the user may access a range of information, such as fuel 
economy 906 or leased vehicle information 908 , or access utilities 910 or a remote 
diagnostics application (RDA) page 912 to monitor, diagnose, and/or repiogram 
vehicle parameters. In this example, the utiUties 910 allow the user to define and/or 
modify vehicle groups 914, specific vehicles 916, and alerts 918. The KDA page 912 
provides users with access to, for example, vehicle information and parametm 920, 
including pages tiiat allowing parameter viewing 922 and reprogramming 924. Note 
that other architectures and implementations are possible for this application as well 
as other applications without departing fi-om the scope of the invention. 
[0076] A "Leased Vehicle Management" (LVM) application is another possible 
option to generate periodic status reports summarizing selected parameters for each 
vehicle in a fleet, such as total vehicle distance, total idle fuel, total idle time, total 
fuel used, and/or total fuel economy. Figure 1 1 is a block diagram illustrating one 
possible example architecture for the Leased Vehicle Management application 950. 
In this example, the user reaches a main page 952 that allows the user to choose 
between a grotq) details page 954 and the task details page 956. Group details 954 
correspond to all information for a selected vehicle group, while task details 956 
correspond to all information for a selected task. The group details page 954 may 
allow the user to, for example, create new tasks (e.g., the timing of data collection for 
a selected vehicle group) 958, generate a report list 960, or generate more detailed 
reports listing specifying, for example, parameter values for a selected report 962J 
The task details page includes similar options, allowing the user to view rq>orts for a 
selected task 964 and generate more detailed reports 966. The task details page 956 
also allows a user to stop a task 968 or delete a task 970. 

[0077] An "Engine Management" application may also be an option to target fleets 
whose vehicles encoimter varying road and traffic conditions, and varying load types 
and weights. The objective of the "Engine Management" s^plication is to improve 
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overall fleet fuel economy via dynamic control of a vehicle's operational 
characteristics, in particular, horsepower ratings and maximum road speed limits. 
Traditionally such operating parameters have been established once at a fleet wide 
level, not taking into consideration some of the variables listed above. In addition, 
making these changes required physical contact with the vehicle, necessitating 
imdesirable vehicle downtime. Dynamic adjustments based upon operating 
conditions can provide reductions in vehicle operational costs, thus resulting in 
significant savings at a fleet leveL With this implication the user will be able to 
dynamically configure the vehicle wherever it may be; tailoring its operational 
characteristics based upon route, load, and other vehicle operation factors. The 
"Engine Management" appUcation may include both measured parameters and 
programmable parameters. Examples of programmable parameters include Vdiicle 
Road Speed Limit, ^gine Horsepower/Torque, Engine Idle Shutdown Time and 
Cruise Control Settings. 

[00781 A "Trip Report" application may also be provided as an option. This 
application allows the fleet manager to obtain trip information from the vehicle on a 
near-real-time basis. The user can analyze trip information for single vehicles as well 
as any increment of their fleet This application primarily uses measured parameters 
such as odometer readings, total trip fuel, idle fuel, average fuel economy, vehicle 
route taken, and others. It also uses some parameters to derive data, such as total idle 
hours and the type of idle hours recorded. The output from this q)plication can also 
be used as input to the billing systems of leasing companies who charge customers 
based upon mileage. 

[0079] A "Maintenance Alert" ^plication allows the fleet manager to establish a 
series of maintenance triggers based upon key parameters. When a parameter 
threshold is encountered, the fleet manager will be notified automatically by the 
system, thus initiating a maintenance event without physical contact with tiie vehicle. 
For example, a fleet may establish a preventive maintenance cycle based upon 
odometer reading. If the server 202 is made aware of the interval, it can notify the 
fleet of the precise moment when that interval occurs. Alerts may provide notification 
on parameters such as diagnostic codes, fluid levels and parameter ranges as well as 
unauthorized tanopering wiOx the vehicle. 
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[0080] A "Vehicle Configuration" application may be offered to allow a fleet 
manager to set certain parameters for multiple vehicles in a fleet so that the selected 
vehicles will operate within its established standards. Examples of parameters include 
horsepower ratings, maximirai road speed limits, maximum and minimum cruise 
control set speeds and maximxmi engine idle time before shutdown. Traditionally, 
this step has required a physical connection of a diagnostic application or tool to tiie 
vehicle, but physical coimections are time-consimiing and require the same step to be 
repeated on every vehicle that is serviced. The wireless nature of the "Vehicle 
Configuration" implication allows operational settings and alerts for sev«^ vehicles 
within a fleet at one time by allowing the user to identify selected vehicles, set 
parameters, and initiate an automated process where each vehicle is systematically 
configured with the same parameter settings. 

[0081] A "Warranty Management" application may also be oflered as part of a data 
mining strategy used by, for example, original equipment manufacture^ (OEMs) to 
help diagnose warranty relationships between major components or to assess warranty 
claims for validity. This application would, for example, obtain detailed vehicle data 
firom the database sender 202d, using both fleet specific and system-wide data mining, 
and then correlate the data with warranty requirements. 

[0082] As noted above, the possible modular £Q)plications described herein are meant 
as illustrative examples only. Further, as noted above, the q>plications 108, 1 10 
accessed by the infi-astructure 102 can be generated by third parties and oSered as 
modules for incorporating into a particular user's interface 106 and accessing the OBU 
105 and other system-supported core services and applications. The modular 
functionality offered by independent £q>plications 108, 110 allows disparate users to 
access the same vehicle data via the same OBUs 105 and ttie same infi:astmcture 102, 
but be offered customized data, fimctionalities, and interfaces that are meaningfiil to 
tiiat user's industry as determined by the particular modular appUcations selected by 
the user. The specific marmer for implementing the applications via, for example, 
computer programs, is within those of skill in the art. 
[0083] The inventive system therefore provides a modular wireless vehicle 
diagnostics, command and control system that is customizable to a user's 
specifications. More particularly, the modular applications 108, 1 10 provide much 
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versatility and allow users from disparate industries to use the same overall inventive 
system 100 by selecting the applications 108, 1 10 relevant to tiieir particular industry. 
Fxirth^", by creating a wireless diagnostics and command and control service, the 
invention provides real-time remote access to vehicles and vehicle systems via, for 
example, the Internet and wireless networks. In one embodiment, the inventive 
system allows users to coimect to multiple data points on any given vehicle to 
interpret and analyze the vehicle data in real time, change vehicle parametm as 
needed and create historical databases to guide future decisions. Furdier, by 
monitoring vehicle operation in real time and providing customized reports for each 
vehicle, the inventive system achieves high operating efficiency, lowered 
maintenance costs and downtime, and even allows pre-ordering of parts as vehicles 
approach scheduled maintraance. 

[0084] Note that the capabilities described above are meant to be illustrative and not 
limiting. The system 100 can be adapted to, for example, establish a setting that is 
applied to selected group of vehicles with a single command rather than individually 
establishing a setting for each vehicle. The aspects of the request, including 
authorization, vehicle/component differences, password differences, and 
configuration limitations of the specific request, may be managed by, for example, the 
server 202. In another embodiment, the system 100 can view each vehicle 104 as a 
single entity to allow the user to communicate with multiple ECLTs on the same 
vehicle 104 at tiie same time. For example, data can be obtained from an Engine ECU 
and Transmission ECU at the same time, with the resultant data from each controller 
correlated to the other to add more detail to the data offered to the user. 
[0085] Variations of the system described above are possible without departing from 
the scope of the invention. For example, selected applications may be run locally on 
proprietary equipment owned by the customers (i.e., the fleet managers, vehicle 
distributors, vehicle dealers and the like) as a stand alone software application instead 
of over the Internet. Further, the OBU 105 can be equipped with, for example, a bar 
code scanner and/or other himian user interface to facilitate data capture. Other user 
interfaces and frmctions, such as a handheld diagnostics tool, woikflow integration 
tool, links between data captured by different applications, and tools to provide 
advance warning of vehicle faults or pre-anival diagnostics information may also be 
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included as application modules or core services or even integrated within the 
application modules tiiemselves. Note tiiat one or more additional servers can also be . 
incorporated into the system to, for example, accommodate additional data 
management functions and/or provide interfaces for integrating with existing 
applications. 

[0086] Information obtained via the inventive system can also be used to, for 
example, re-calibrate vehicle components, perform firmware downloads, perform 
component failmre analysis, determine wear characteristics, analyze quality of 
components used in their manufacturing processes, retrieve and manage wairanty 
information, receive indications of vehicle maintenance needs, monitor vehicle use 
and abuse, and/or monitor lessee trip information, perfomi proactive data analysis, 
perform pre-anival diiagnostics, re-calibrate vehicle components, and/or perform 
firmware downloads. Note that this list of options is not exhaustive and those of skill 
in the art will understand that other variations in the data obtained via fhe inventive 
system and how the data is presmted and used can vary witihiout dq>arting fix>m the 
scope of tbe invention. 

[0087] It should be understood that various alternatives to the embodiments of the 
invention described herein may be employed in practicing the invention. It is 
intended that the following claims define the scope of the invention and that the 
method and apparatus within the scope of these claims and their equival^ts be 
covered thereby. 
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1 . A system for monitoring, configuring, progranuning and/or diagnosing 
operation of at least one vehicle, comprising: 

an on-board unit disposed on the vehicle to send and receive data 
corresponding to at least one vehicle operating characteristic; 

a plurality of modular applications, each application having an associated 
function that processes the data corresponding to said at least one vehicle operating 
characteristic obtained via the on-board unit; and 

an interface that allows selection among the plurality of modular applications 
to create a customized system. 

2. The system of claim 1 , wherein the on-board imit includes: 

at least one on-board unit interface to support communication between the on- 
board unit and at least one device outside the on-board unit; 

a processor that manages the data sent and received by the on-board unit via 
said at least one interface; and 

a memory coupled to the processor. 

; 

3 . The system of claim 2, wherein said at least one on-board unit 
intoiace is at least one selected from the group consisting of: 

a wireless interface that supports conomunication with a wireless 
commimication system; 

a vehicle interface that supports communication with at least one vehicle 
component via a vehicle data bus; 

a user interface that supports communication with a user; 

a serial interface that supports communication with at least one of a driver 
interface and an on-vehicle device; and 

a global positioning interface that supports conununication witii a global 
positioning system (GPS) device. 



25 



wo 03/077205 PCT/US03/06475 

4. The system of claim 3, wherein (he vehicle interface includes at least 
one selected from the group consisting of: 

a data parser/requester module that handles non-application specific 
interfacing between the processor and the vehicle data bus; and 

an application specific module coupled to the data parser/requestor module 
that handles application specific interfacing between the processor and the vehicle 
data bus. 

5. The system of claim 1, wherein the modular eq^plications are selected 
from the group consisting of third-party appUcations, system-supplied q>plicatioxis, 
and core services. 

6. The system of claim 5, wherein at least one of the third-party 
applications and system-supplied applications fimction using information from at least 
one core service. 

7. The system of claim 5, wherdn the core services include a sn£q>shot 
service that obtains a set of vehicle parameter values over time. 

8. The system of claim 7, wherein the snapshot service causes the on- 
board imit to cache a selected number of parameter readings with respect to a 
triggering event. 

9. The system of claim 8, wherein the on-board unit caches the selected 
niunber of parameter readings by storing a plurality of parameter readings at selected 
time intervals. 

10. The system of claun 5, wherein the core services include a get stored 
values service that outputs at least one vehicle controller value in response to a 
request, wherein the get stored values service outputs a cmrent vehicle controller 
value if the vehicle controller is available at the time of the request and output a stored 
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vehicle controller value in the on-board unit if the vehicle controller is not available at 
the time of the request. 

1 1 . The system of claim 1 0, wherein the get stored values service collects 
vehicle controller values at a selected time interval and stores a most recent vehicle 
controller value as the current vehicle controller value. 

12. The system of claim 5, wherein the core services include an alert 
service that detects at least one of a solicited fault and an unsolicited fault. 

13. The system of claim 12, wh^in the alert service detects a solicited 
fault by filtering faults and outputting only faults solicited by a user. 

1 4. The system of claim 12, wherein the alert service includes at least one 
of the functions from the group consisting of adding and removing individual faults, 
cancelling the alert service for a given fault after an alert has been fired, firing an alert 
after a parameter exceeds a selected threshold for a selected time period, and 
con[^>aring a saved parameter with a current parameter to detect tampering. 

15. The system of claim 5, wherein the core services include a change 
parameter service that changes at least one vehicle parameter in response to a request. 

1 6. The system of claim 1 , wherein tiie interface is at least one selected 
from the group consisting of: 

a user interface that siq>ports interaction with a human us»; and 
a machine-to-machine interface. 

17. The system of claim 16, wherein the user interface is a graphical user 
interface. 

18. The system of claim 1, further comprising a server linking the on- 
board unit to the interface via the modular applications. 
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1 9. The system of claim 1 8, wherein the server includes at least one of the 
group consisting of: 

a web/application server containing logic defining the modular applications; 
a vehicle server that acts as a translator between the modular applications and 
the on-board unit; 

a contimunications server to support communication via a wireless network; 

and 

a database server containing at least one relational data table retaining 
infonnation associated with the vehicle. 

20. The system of claim 18, wherein at least one of the server and the 
modular applications form an appUcation service provider (ASP) infrastructure. 

21 . The system of claim 1, wherein the plurality of modular applications 
include a remote diagnostics application. 

22. The system of claim 1, wherein the plurality of modular applications 
include a leased vehicle manag^ent application. 

23. The system of claim 1, wherein the plurality of modular applications 
includes at least one from the group consisting of a remote diagnostics application, a 
leased vehicle management application, a fuel economy £q>plication, a vehicle locating 
application, a trip reporting appUcation, an engine management application, a 
maintenance alert application, a vehicle configuration application, and a warranty 
management ^plication. 

24. The system of claim 1, wherein at least one of the plurality of modular 
applications correlates data between at least two vehicle controllers on flie same 
vehicle. 
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25 . The system of claim 1 , wherein at least one of the plurality of modular 
applications establishes a setting for a plurality of vehicles with one command sent 
via the interface. 

26. An on-board unit disposed on a vehicle for use in a system for 
monitoring, configuring, programming and/or diagnosing operation of at least one 
vehicle, comprising: 

at least one on-board unit interface to siipport communication between the on- 
board unit and at least one device outside the on-board unit; ' 

a processor that manages the data sent and received by the on-board unit via 
said at least one interface; and 

a memory coupled to the processor. 

27. The on-board iinit of claim 26, wherein said at least one on-board unit 
interface is at least one selected from the group consisting of: 

a wireless interface that supports communication with a wireless 
communication system; 

a vehicle interface that supports communication with at least one vehicle 
conq>oxient via a vehicle data bus; 

an on-board user interface that supports communication with a usen 

a serial interface that siq>ports communication with at least one of a driver 
interface and an on-vehicle device; and 

a global positioning interface that supports communication with a global 
positioning system (GPS) device. 

28. The on-board unit of claim 27, wherein the vehicle interface includes 
at least one selected from the group consisting of: 

a data parser/requester module that handles non-application specific 
interfacing between the processor and the vehicle data bus; and 

an application specific module coupled to the data parser/requestor module 
that handles application specific interfacing between the processor and the vehicle 
data bus. 
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29. A method for monitoring, configuring, programming and/or 
diagnosing operation of at least one vehicle, comprising: 

obtaining data corresponding to at least one vehicle operating characteristic 
firom an on-board unit on the vehicle; 

providing a plurality of modular applications that are selectable by the user to 
create a customized system; and 

processing the data corresponding to at least one vehicle operating 
characteristic obtained via the on-board unit according to at least one function 
associated with at least one selected modular application. 

30. The method of claim 29, further comprising obtaining a set of vehicle 
parameter values over time. 

31. The method of claim 30, wherein the obtaining step includes: 
detecting a triggering event; and 

caching a selected number of parameter readings with respect to a triggering 

evCTt. 

32. The method of claim 3 1 , wherein the caching step includes storing a 
plurality of parameter readings at selected time intervals. 

33. The method of claim 29, further conq)rising: 
detecting a request for a vehicle controller value; 

outputting a current vehicle controller value if a vdiicle controll^ is available 
at the time of the request; and 

output a stored vehicle controller value if the vehicle controller is not available 
at the time of the request. 

34. The method of claim 33, further comprising collecting vehicle 
controller values at a selected time interval and storing a most recent vehicle 
controller value as the current vehicle controller value. 
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35. The method of claim 29, fiirther comprising: 

detecting at least one of a solicited fault and an unsolicited fault; and 
firing an alert after the detecting step. 

36. The method of claim 35, wherein detecting a solicited fault includes 
filtering faults to ou^ut only faults solicited by a user. 

37. The method of claim 35, further comprising at least one step selected 
fix>m the group consisting of adding and removing individual faults, cancelling the 
alert service for a given fault after an alert has been fired, firing an alert after a 
parameter exceeds a selected threshold for a selected time period, and comparing a 
saved parameter with a ciurent parameter to detect tampering. 

38. The method of claim 29, further comprising changing at least one 
vehicle parameter in response to a request. 

39. The method of claim 29, further comprising translating data between 
the modular applications and the on-board unit. 

40. The method of claim 29, wherein the providing step includes providing 
a remote diagnostics application. 

41 . The method of claim 29, wha:ein the providing step includes providing 
a leased vehicle management implication. 

42. The method of claim 29, wherein the providing step provides at least 
one firom the group consisting of a remote diagnostics application, a leased vehicle 
management application, a fiiel economy application, a vehicle locating application, a 
trip reporting application, an engine management appUcation, a maintenance alert 
^plication, a vehicle configuration application, and a warranty management 
q>plication. 
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43. The method of claim 29, further comprising correlating data between 
at least two vehicle controllers on the same vehicle. 

44. The method of claim 29, wherein at least one of the plurality of 
modular applications establishes a setting for a pluraUty of vehicles with one 
command sent via the interface. 
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